The invention relates to the interworking of Third Generation Partnership Project (3GPP) Public Land Mobile Networks (PLMNs) i.e. General Packet Radio Service/Universal Mobile Telephony System (GPRS/UMTS) and Wireless Local Area Network (WLAN) access networks, commonly known as I-WLAN. It also relates to the planned/anticipated evolution of the current 3GPP network (i.e. GPRS/UMTS) architecture into a somewhat simplified and more multi-access oriented form, as being worked out by the 3GPP. This evolution and its related activities in the 3GPP are commonly referred to as System Architecture Evolution (SAE).
I-WLAN is being specified by the 3GPP and the functional description is provided in 3GPP TS 23.234 v6.4.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP system to Wireless Local Area Network (WLAN) interworking; System description (Release 6).
One of the I-WLAN scenarios specified by the 3GPP is the WLAN 3GPP IP Access. FIG. 1a shows a reference model of the roaming variant of the WLAN 3GPP IP Access, where a WLAN Access Network 100 is connected to a 3GPP Visited Network 110. A WLAN User Equipment (UE) 120, i.e. the I-WLAN terminal also referred to as a user terminal, is located in an area controlled by the WLAN access network 100 connected to the visited network 110. The UE 120, which can also be called user terminal or just terminal, has a further connection to the home network 130, i.e. to a gateway 140, referred to as the Packet Data Gateway (PDG), via the Wu interface 150. Although this connection physically goes via the WLAN access network 100 and the visited network 110, it is depicted in FIG. 1a as a direct line between the UE 120 and the PDG 140, because the line represents the logical interface between the UE 120 and the PDG 140. The WLAN access network 100 has connections to the gateway 160 of the visited network 110, referred to as WLAN Access gateway (WAG) via the Wn interface 170 and to an Authentication, Authorization and Accounting (AAA) proxy 180 via the Wa interface 210. The WAG 160 is also connected to the AAA proxy 180 via the Wg interface 200. The gateways of the home and the visited networks are connected via the Wp interface 190. Moreover, the AAA proxies of the home and the visited network are connected via the Wd interface 220. The entities of FIG. 1a not described are not relevant for the invention and are only included to give a more complete picture of the network architecture.
In the context of this invention only a scenario denoted WLAN 3GPP IP Access scenario is of interest and therefore the WLAN 3GPP IP Access scenario is assumed in all further descriptions, unless explicitly stated otherwise.
In the WLAN 3GPP IP Access scenario the traffic between an I-WLAN terminal accessing a WLAN access network and a peer on the Internet is tunneled between the terminal and the home PLMN, via the WLAN access network and the visited PLMN, and routed between the tunnel endpoint in the home PLMN and the peer on the Internet. This is referred to as home tunneling. As an option the traffic may instead be tunneled between the I-WLAN terminal and the visited PLMN, without involving the home PLMN in the traffic processing, which is referred to as local breakout.
The tunnel traverses the Wn and Wp interfaces. When traversing the Wn interface the tunnel may traverse untrusted networks with unknown capabilities, e.g. the Internet. On the Wp interface the traversed networks are regarded as secure, either operator internal networks or the inter-operator network GPRS roaming exchange (GRX).
The tunnel endpoint in the home or visited PLMN is a gateway, either the PDG or the Tunnel Terminating Gateway (TTG) These two nodes should be regarded as alternative implementations where in the TTG case the PDG functionality is split between the TTG and the GGSN, but theoretically it would be possible to have both types of implementations in the same network.
When an I-WLAN terminal attempts to access a WLAN access network, the WLAN access network has the option to authenticate the user before granting the access. If the WLAN access network chooses to use this option (which will probably be more common than the opposite), it uses the Authentication, Authorization and Accounting (AAA) infrastructure to authenticate the identity of the user, aided by the AAA server in the user's home PLMN. The authentication mechanism is either EAP-AKA as described in J. Arkko, H. Haverinen, “” Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), RFC 4187, January 2006 or EAP-SIM as described in H. Haverinen, J. Salowey, “Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)”, RFC 4186, January 2006, which is communicated transparently between the terminal and the home AAA server, via the AAA proxy in the visited PLMN in the roaming case.
When the user is permitted access to the WLAN access network (whether authenticated or not), the terminal uses Internet Key Exchange version 2 (IKEv2), further described in Charlie Kaufman et al., “Internet Key Exchange (IKEv2) Protocol”, RFC 4306, December 2005, to establish an IPsec tunnel, further described in S. Kent, Rt. Atkinson, “Security Architecture for the Internet Protocol”, RFC 2401, November 1998, and S. Kent, K. Seo, RFC 4301, with the same title, to the PDG/TTG in the home PLMN via the WAG in the selected visited PLMN. Optionally, the IPsec tunnel may be established between the terminal and the PDG/TTG in the visited PLMN instead of the PDG/TTG in the home PLMN. The terminal uses the WLAN Access Point Name (W-APN), which is stored in the Subscriber Identity Module (SIM) or the Universal Subscriber Identity Module (USIM) (on the Universal Integrated Circuit Card (UICC)), to determine the IP address of the PDG/TTG to be used as the remote tunnel endpoint. The W-APN, which constitutes a domain name consisting of a Network Identifier and an Operator Identifier (in that order), is resolved into an IP address through regular Domain Name System (DNS) mechanisms.
In IKEv2 EAP-AKA or EAP-SIM is used as an integrated mechanism to authenticate the user to the PDG/TTG during the tunnel establishment. The PDG/TTG communicates with the AAA server in the home network via a AAA protocol, preferably Diameter e.g. described in Pat Calhoun et al., “Diameter Base Protocol”, RFC 3588, September 2003, and P. Eronen et al., “Diameter Extensible Authentication Protocol (EAP) Application”, RFC 4072, August 2005, to have the user authenticated.
When the IPsec tunnel is established, the PDG/TTG assigns an “inner” IP address to the terminal.
If the tunnel endpoint in the PLMN is a TTG, then the TTG also establishes a GTP tunnel to the GGSN and associates the IPsec tunnel and the GTP tunnel with each other. Then the regular traffic through the tunnel(s) can commence.
The basic tasks of the WLAN Access Gateway (WAG) in addition to routing packets between the WLAN access network and the PDG/TTG include:                Count packets and generate accounting data when the PDG/TTG is located in another network.        Simple packet filtering based on unencrypted information in the IP header. The packet filters are derived from policy enforcement information transferred to the WAG 160 (over the Wg interface) from the home AAA servers 230 of the concerned subscribers (via the Wd 220 interface and the AAA proxy 180 in case the WAG is located in the visited PLMN).        
Selection of PDG/TTG is provided via DNS based on a Fully Qualified Domain Name (FQDN) derived from the W-APN and the PLMN ID (i.e. the HPLMN ID or the VPLMN ID). When a TTG is used, the Network Service Access Point Identifier (NSAPI) allocation requires that for a given user, all tunnels towards W-APNs served from the same GGSNs should be directed to the same TTG.
One long-term target architecture that has been considered in the architecture evolution work includes an overall multi-access core network with AENs (Access Edge Nodes) at the edges according to FIG. 1b. An AEN is thought of as an evolution of an advanced version of a GPRS Support Node labeled “GSN+”. A GSN+ 430 is in turn an evolved version of the GPRS Support Node (GSN) in the current 3GPP network architecture. FIG. 1b illustrates a Home network 300 comprising an AEN 310 and policy and charging control functions 320 and a visited network 400 also comprising an AEN 410 and policy and charging control functions 420. A roaming interface 440 is provided between the home and the visited network. The AEN of the visited network is further connected to different access networks such as Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/Enhanced Data rates for GSM Evolution (GSM/EDGE), Public WLAN and various variants of Digital Subscriber Line (xDSL, where x can represent various letters, such as A for “Asymmetric”, S for “Symmetric”, H for “High speed” or V for “Very high speed”) access networks. The AENs comprise common access independent (but to a certain extent “access aware”) functionality that is used for all accesses. In addition there is an access dependent part for each specific access technology served by an AEN. An AEN may be realized as multiple cooperating nodes.
Regarding I-WLAN the evolution strategy is to simplify the architecture and to incorporate the nodes/functions more closely into the general 3GPP architecture than in the current specifications. In the long-term target architecture it is proposed that the PDG/TG and the WAG be merged into the AEN. Possible intermediate stages may include that the PDG/TTG is merged into future evolved GPRS support nodes (GSN+), that the PDG/TTG and the WAG are merged into future evolved GPRS support nodes (GSN+) or even that the PDG/TTG and the WAG are merged. The view of the evolved future network architecture is not stable yet and hence the result of this work in the 3GPP may well be something that is different from what is illustrated in FIG. 1b. Another proposed evolved network architecture is illustrated in FIG. 1c. The AEN in the evolved network architecture as depicted in FIG. 1b is more or less equal to a combination of nodes referred to as the Inter Access System Anchor (IASA), the Mobility Management Entity (MME) and the User Plane Entity (UPE) in the evolved network architecture illustrated in FIG. 1c. FIG. 1c illustrates the scenario when both home routed traffic and local breakout traffic are routed via the visited Inter AS Anchor (v-IASA) in the roaming case. It should be noted that the AAA server is assumed to be integrated in the Home Subscriber Server (SS). The visited network comprises a GPRS core network 530 and an Evolved Packet Core (EPC) 500 comprising the IASA 520 and the MME 510 and the UPE 510. The visited GPRS core network 530 is connected to a plurality of different access networks such as GSM EDGE radio access network (GERAN), UMTS Terrestrial Radio Access Network (UTRAN) and evolved Radio Access Network (evolved RAN) while the IASA 520 of the visited EPC 500 is connected to a WLAN which is of interest for the present invention. The visited IASA 520 is connected to a policy control resource function 540 of the visited network, to the HSS 620 of the home network and to the IASA 610 of the home EPC 600.
In SAE, which extends the system to multi-access (through heterogeneous accesses), two “tiers” of mobility management are assumed: one tier for the inter access mobility (i.e. mobility between access networks of different types) and one tier for the “internal” mobility in the 3GPP domain. Both tiers utilize anchor nodes as a stable point for the traffic. The Inter Access System Anchor (IASA) is the anchor node for the inter-access mobility and the User Plane Entity (UPE) is the anchor node for the intra-3GPP domain mobility. The UPE is a pure user plane node and it is complemented by the Mobility Management Entity (MME) which handles the control plane for the intra-3GPP domain mobility management (as well as other access related signaling).
In FIG. 1c, the roaming with home tunneling case involves two IASA nodes, one visited IASA (v-IASA) in the visited PLMN and one home IASA (h-IASA) in the home PLMN. In this description the IASA that is closest to the terminal/UE is denoted “serving IASA” (s-IASA). In the non-roaming case the s-IASA is the h-IASA and in the roaming with local breakout case the s-IASA is the v-IASA. In the architecture illustrated in FIG. 1c the s-IASA is the v-IASA in all roaming cases, both for local breakout and for home tunneling/home routing.
The SAE architecture includes an anchor node for inter-access system mobility. This anchor node is assumed to be a Mobile IP (MIP) Home Agent (HA). Preferably it is a Mobile IPv6 (MIPv6) HA, but it may also turn out to be a Mobile IPv4 (MIPv4) HA. The HA will probably be integrated in, or co-located with, the h-IASA. Whether the h-IASA corresponds to a single HA or multiple (e.g. for redundancy or load sharing purposes) is not decided and may not have to be specified at all.
Local breakout in I-WLAN, i.e. the scenario when the UE-PDG/TTG tunnel is established between the UE and PDG/TTG in the visited PLMN (henceforth denoted PDGv/TTGv), is possible also in the current I-WLAN solution, to a certain extent under the control of the home operator.
To select local breakout the user/UE constructs an FQDN using the W-APN Network Identifier and the VPLMN ID as the Operator Identifier and performs a DNS query to resolve the FQDN into one or several PDGv/TTGv IP addresses) (i.e. using information originating in a DNS server in the VPLMN). It should be noted that the terms “DNS server”, “DNS name server” and “name server” are regarded as synonyms in this description. Then the IPsec tunnel is established between the UE and the PDGv/TTGv using IKEv2 and with the home AAA server authenticating and authorizing the user/UE.
To select home tunneling (the basic case i.e. non-local breakout) the user/UE constructs an FQDN indicating the HPLMN.
When local breakout is used, the HPLMN authorizes the local breakout through the AAA communication between the PDGv/TTGv and the home AAA server. If the policy of the HPLMN does not allow local breakout (for this user, W-APN, VPLMN or any combination of these), then the home AAA server sends a rejection message to the PDGv/TTGv, which in turn rejects the tunnel establishment. The user/UE may then start the W-APN resolution and tunnel establishment procedure all over again using an FQDN indicating the HPLMN.
If the user/UE has selected home tunneling, but the policy of the HPLMN mandates/prefers local breakout, then the home AAA server can either reject the tunnel establishment or accept it in spite of the policy. If the tunnel establishment is rejected, the UE will not retry tunnel establishment towards the VPLMN according to 3GPP TS 23.234 v6.4.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP system to Wireless Local Area Network (WLAN) interworking; System description (Release 6)“”.
The home AAA server may provide the PDG and the WAG with packet filter instructions. When a TTG is used the intention is to reuse the packet filtering functionality of the GGSN, but nothing prevents that the home AAA server still provides the TTG with packet filter instructions. When the PDG/TTG and/or WAG is located in the VPLMN, the home AAA server provides the packet filter instructions via the AAA proxy in the VPLMN.
As mentioned above, in the TTG case it is required that for a given user, all tunnels towards W-APNs served from the same GGSNs should be directed to the same TTG. Currently there is no existing solution for this. The TTG address is selected and returned via DNS solely based on the FQDN that is derived from a W-APN and a PLMN ID. There is no user information available to aid the TTG IP address selection.
The allocation of the serving IASA (or AEN) when a non-3GPP access (or an evolved I-WLAN access) is used is to a large extent still an open issue. The s-IASA is supposed to be selected/allocated by an access node in the access network, generally denoted Access Gateway (AGW), based on the user ID and policies. This is a very high-level assumption without any technical details provided.
Allocation of a Mobile IPv6 Home Agent is assumed to be performed via DNS, according to the principles put forth by the IETF Mobility for IPv6 working group in J. Giaretta “Mobile IPv6 bootstrapping in split scenario”, internet-Draft: draft-ietf-mip6-bootstrapping-split-02, March 2006.
The UE uses the regular DNS mechanisms to resolve an FQDN associated with its Home Agent and the DNS system returns an IP address of an allocated Home Agent. There are two ways to go about, denoted the “HA DNS lookup by name” method and the “HA DNS lookup by service” method respectively.
If the UE is configured with an FQDN of a Home Agent, it sends a DNS query with the QNAME set to the HA FQDN, e.g. “ha.home-operator.com”, and the QTYPE set to “AAAA”. In response the DNS server returns an IP address belonging to the Home Agent. This is the “HA DNS lookup by name” method.
The UE does however not have to be configured with an FQDN of a Home Agent. It is enough that it is configured with an FQDN representing its home operator, e.g. “home-operator.com”. In such case the UE sends a DNS query with the QNAME set to “—mip6._ipv6.home-operator.com” and the QTYPE set to “SRV” (indicating a request for a service resource record). In response the DNS server returns a list of one or more FQDNs belonging to the available Home Agents, of which the UE selects one. The DNS server may also include the IP addresses of the Home Agents in addition to the FQDNs. Otherwise the UE has to request the DNS system to resolve the FQDN of the selected HA into an IP address as described for the “HA DNS lookup by name” method. This is the “HA DNS lookup by service” method.
The same methods may be used for allocation of a Mobile IPv4 Home Agent, when a co-located care-of address is used (i.e. when no Foreign Agent is used). When a Foreign Agent is used, the Foreign Agent could use the above methods to have a Home Agent allocated on behalf of the UE.
In the context of HPLMN controlled local breakout, the initial choice of whether to use local breakout or home tunneling lies entirely with the user/UE. The HPLMN can only accept or reject this choice through the AAA protocol.
A rejection of local breakout can also be seen as an implicit redirection of the local breakout tunnel to a home tunnel, since the rejection will cause the UE to attempt a new tunnel establishment by using a new FQDN towards the home network.
A rejection of home tunneling will not cause an implicit redirection to a local breakout tunnel. Thus, rejection of home tunneling in practice means that network access is rejected (except for possible WLAN Direct IP Access traffic).
Hence, the HPLMN can only affect the initial choice of the user/UE in one direction, i.e. from local breakout to home tunneling, not the other way around. In addition, the implicit means that the HPLMN has to redirect the UE from local breakout to home tunneling, i.e. rejection triggering a new tunnel establishment attempt to the home network, is inefficient and slow, significantly increasing the access delay. IPsec tunnel establishment using IKEv2 is not a very swift procedure. Therefore, rejecting one tunnel establishment procedure to initiate a new one (with preceding DNS procedure) introduces a delay that the user may perceive as inconvenient. Moreover, the redundant double tunnel establishment procedure unnecessarily consumes resources in the involved networks.
A problem with the s-IASA selection mechanism is that there are no details provided beyond the statement that the AGW selects the s-IASA based on user-ID and policy.
A problem with the currently proposed solution for HA allocation in SAE is that it provides the HPLMN with very poor means for flexible selection of the HA. It basically enables no other flexibility than a plain load-sharing scheme. It completely lacks means for HA selection/allocation based on relevant information, such as policies, user specific conditions, VPLMN, etc.